Does this PR make a difference to something? From what I understand, the kernel value is upcast into float before doing any accumulation (and accumulation is anyway in f32). So unless there are kernels around which don't fit into f16 I don't see a benefit to supporting this, especially when we don't support the f16 inputs yet (which incidentally might be more relevant than kernels being f32 as we could potentially do half2 multiplications)

So the motivations of this PR are:

1. Currently in ggml_backend_cuda_device_supports_op it always returns true for GGML_OP_CONV_TRANSPOSE_2D without checking the kernel type, thus may cause crashes when actually computing. This PR fixs this mismatching behavior.

   llama.cpp/ggml/src/ggml-cuda/ggml-cuda.cu

   Lines 4061 to 4064 in 8e878f0

   	case GGML_OP_CONV_TRANSPOSE_2D:
   	case GGML_OP_POOL_2D:
   	case GGML_OP_ACC:
   	return true;

2. Some recent models are natively BF16, and using F16 kernel can lead to overflows. F32 is safe here and can be readily used for precision verification.

So the motivations of this PR are:

1. Currently in ggml_backend_cuda_device_supports_op it always returns true for GGML_OP_CONV_TRANSPOSE_2D without checking the kernel type, thus may cause crashes when actually computing. This PR fixs this mismatching behavior.

That's because it matches the CPU capabilities exactly

2. Some recent models are natively BF16, and using F16 kernel can lead to overflows. F32 is safe here and can be readily used for precision verification.

That would be a problem in a conversion to GGUF, not necessarily a problem to be solved here.

You should add the CPU version for the f32 kernel too, that way this PR makes more sense

Hi @am17an, thanks for reviewing this PR.

Here’s what has been updated:

1. Simplified CUDA kernel dispatch logic.
2. Renamed type_kernel to kernel_type.
3. Introduced a templated ggml_compute_forward_conv_2d_transpose_impl to reduce duplication.

Please let me know if there’s anything else you’d like changed.